Google Chrome 141 byl prohlášen za stabilní. Nejnovější stabilní verze 141.0.7390.54 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Za nejvážnější z nich (Heap buffer overflow in WebGPU) bylo vyplaceno 25 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
eDoklady mají kvůli vysoké zátěži technické potíže. Ministerstvo vnitra doporučuje vzít si sebou klasický občanský průkaz nebo pas.
Novým prezidentem Free Software Foundation (FSF) se stal Ian Kelling.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za září (YouTube).
Vyšla kniha Počítačové programy a autorské právo. Podle internetových stránek nakladatelství je v knize "Významný prostor věnován otevřenému a svobodnému softwaru, jeho licencím, důsledkům jejich porušení a rizikům „nakažení“ proprietárního kódu režimem open source."
Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Do konference přišlo celkem 1537 emailů, nejvíce jich poslali Andrew Morton, William Lee Irwin III a Adrian Bunk.
29. črv - 8. črc
Linas Vepstas napsal:
Firmware může hlásit chyby kdykoliv a není to neobvyklé ani při bootu. Jenže tyto zprávy nejsou k ničemu do chvíle, kdy naběhne rtasd, což je poměrně pozdě. V důsledku toho jsou chyby firmawaru během bootu tiše ignorovány.
Tenhle patch je alespoň vypíše pomocí printk, takže se objeví v boot.msg/syslog. Existují ještě dva logovací mechanismy, které jsem radši nechal na pokoji, protože nerozumím jejich chování. Především nvram není povoleno až do pozdní fáze bootu... Ale jaký má pak nvram logování smysl, jestli ne zachytávat zprávy, které se objevily časně během bootu?
Paul Mackerras odpověděl: Printk vypisující chyby je otravné a nezdá se mi to příliš přínosné vzhledem k tomu, že jde jen o nečitelná hexová čísla, kterých může být opravdu moc. Musí existovat lepší způsob. Dát to do nvram se mi zdá jako lepší možnost. Neznám důvod, proč bychom nemohli nvram používat hned zkraje.
Jake Moilanen poznamenal: nvram můžeme inicializovat velmi brzy, ale události v nvram uložené bychom neměli zahazovat, dokud neběží rtasd a ty události si nevytáhne, protože by mohlo jít o tu chybu, která minule při bootu systém shodila. Mohli bychom asi rtasd nastartovat o trochu dříve, ale nepřipadá mi, že by nás to mělo tolik trápit.
Greg KH celou záležitost považoval za diskutabilní, protože Linas by měl prostě použít syslog nebo netlink jako celý zbytek kernelu. Nevynalézejte znovu kolo.
Paul také Linasovi řekl: Tento typ problému se obyčejně řeší pomoci netlinku. Myslím, že by dávalo smysl vypisovat pomocí printk RTAS chybové události se závažností "fatal" a možná i "error". Varování a události by však měly být poslány na rtasd.
Hollis Blanchard napsal: Už jsem se na to ptal dříve a bylo mi řečeno, že neexistuje způsob, jak zjistit závažnost události bez předchozího úplného zpracování binárních dat. Byl bych nadšen, kdybych se mýlil...
Nathan Fontenot odpověděl:
Zjistit závažnost RTAS události lze a ani to není moc náročné. Podívej se na asm-ppc64/rtas.h, kde najdeš definici hlavičky RTAS události (struct rtas_error_log). Všechny RTAS události mají počáteční hlavičku obsahující závažnost dané události.
Dekódování RTAS událostí za hranicemi hlavičky je po chvilce pěkně nechutné a doufejme, že to v jádře nikdy nebude potřeba dělat.
4. črc - 14. črc
Norberto Bensa si všiml, že XFS vynuluje soubory po nekorektním vypnutí. Zeptal se, jestli existuje způsob, jak se tomu vyhnout. L. A. Walsh odpověděla, že jde o starý problém, který byl již dříve hlášen v XFS konferenci; ale dodala:
Zjevně to nelze snadno reprodukovat, nikdo nemá tušení, proč se tak děje. Prostě to dělá. I po několika synchronizacích jsou někdy soubory editované během posledních několika dní vynulovány. Dobrý důvod pro pořizování denních záložních kopií, protože ty většinou obsahují bezchybné soubory...
Kdybych jen mohla přijít na to, jak to reprodukovat... když se o to
pokusím, nic se nestane. Grrr... ví, že kontroluji! 
Chris Wedgwood během diskuze řekl:
XFS soubory nevynulovává, pouze vrací nuly místo nezapsaných úseků. Otevřete-li existující soubor a celý jej popíšete, možná během spadnutí uvidíte stará data, nebo nová data, pokud byla zapsána [flush]. Neměli byste však vidět nuly.
Hádám, že u jiných filesystémů (když se žurnálují pouze metadata) jsou bloky alokované pro nově zapsaná data většinou stejné jako nedávno uvolněné bloky, takže to vypadá, že všechno funguje, ale ve skutečnosti je to pravděpodobně pouze náhoda. XFS by se mohlo chovat podobně, ale dříve nebo později byste na to stejně doplatili, když byste dostali nesmysly místo starých dat.
Některé aplikace je prostě potřeba opravit.
L. A. odpověděla:
Nevím, jestli to nějak pomůže (pochybuji, mě to mate)... Soubory, které jsem zapsala ve vimu, a které vrátily "nuly", byly soubory napsané před 2 - 3 DNY -- přičemž čerstvější zápisy byly často uloženy bez problémů.
Kdyby to byl soubor, který jsem právě editovala, a v tu chvíli to spadlo, to bych to chápala lépe než soubory, kterých jsem se pár dní nedotkla.
Chris řekl, že podobné chování skutečně nikdy neviděl, rozhodně pak ne u souborů, které byly upraveny před několika dny. Byl si jistý, že na jeho systému by checksum skripty, které kontrolují všechny jeho soubory, něco takového zachytily. Jeho odhad v odpovědi na popis od L. A. byl, že soubory jsou skutečně nějak měněny, ale nedělá to XFS.
5. črc - 8. črc
Andrew Morton oznámil Linux 2.6.7-mm6:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/pat ches/2.6/2.6.7/2.6.7-mm6/
8. črc - 14. črc
Erik Rigtorp napsal: Tento patch do swsusp přidává podporu pro bootsplash. Na kódu, který je rozhraním k bootsplash, je ještě nutné pracovat, v této chvíli je víceméně ukradený ze swsusp2. Nějaký další kód by šlo místo toho pravděpodobně přesunout do console.c.
Christoph Hellwig poukázal na to, že CONFIG_BOOTSPALSH není v současné době v oficiálním stromu jádra; takže podporovat to u software suspend je předčasné. Christoph rovněž naznačil, že CONFIG_BOOTSPALSH v hlavním stromu vítáno není. Pavel Machek odpověděl:
Ten patch nebyl určen pro hlavní strom... Ale i tak se bude hodit, protože velká distra tenhle druh věcí chtějí...
Možná by CONFIG_BOOTSPLASH nakonec v hlavní stromu být mělo. Vůbec se mi nelíbí představa dvou nekompatibilních sad háčků do swsusp....
Ale Christoph řekl: Ne. Tyhle věci nemají v kernelu co dělat. Malujte si své pěkné obrázky přes fbdev. A ten bootsplash patch od SUSE je totální humus - vždyť co musíš hulit, abys dal JPEG dekodér do jádra?
Stefana Reinauera se to dotklo a napsal:
Souhlasím, že v případě jádra 2.6 by to šlo udělat lépe díky pořádné podpoře initramfs, ale v 2.4 nebyl žádný rozumný způsob, jak vložit uživatelský kód dost brzy na to, aby byl spuštěn před inicializací framebufferu.
Na druhou stranu, ten JPEG dekodér má 8k - méně než desítky gzip/gunzip algoritmů v kernelu. Takže stěžování mi přijde trochu hloupé. Jestli chceš jen držkovat, pak běž kritizovat to, že s rozlišením 1024x768 sežere bootsplash nadobro 1.5MB paměti. Pokud něco, tak TO by dávalo smysl.
A jestli chceš retro textové hlášky nebo grafický boot, to je dozajista filosofická otázka. Dle mého skromného názoru není možné tak brzy startovat X.
Pavel pak také Christophovi řekl:
SUSE verzi bootsplashe jsem neviděl... Ani nechci vidět. Ale takhle má SUSE svůj mizerný bootsplash, RedHat pravděpodobně také, Mandrake asi také, atd.
A teď bude chtít SUSE splash u swsusp, RedHat pravděpodobně také, Madrake asi také, atd. Nechce se mi trápit se třemi různými sadami háčků do swsusp.
Takže... kdyby si pročištěný bootsplash našel cestu do jádra, mohlo by to zmírnit množství humusu v distribucích. Aspoň by existoval jednotný způsob, jak tu věc vypnout...
Christoph odpověděl: Red Hat to dělá správně, protože používá program, který využívá fbdev. Zároveň také nemají žádnou podporu pro swsusp, což dává docela smysl, když vezmeme v potaz, jakým tempem se ten kód i nadále mění.
V originálu Kernel Traffic 270 vyšla navíc ještě tato témata:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz